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FOREWORD 


The  IRIG  106,  Telemetry  Standards,  documents  have  taken  on  a  new  look  effective  with  this 
release.  The  IRIG- 106  is  now  published  in  two  parts.  Part  I  contains  the  more  familiar 
information  and  standards  that  have  evolved  over  the  years.  Part  II  is  a  totally  new  entity  that  is 
devoted  to  the  standards  associated  with  the  present  technological  evolution/revolution  in  the 
telemetry  networks  area. 

The  Telemetry  Group  (TG)  of  the  Range  Commanders  Council  (RCC)  has  prepared  this 
document  to  foster  the  compatibility  of  telemetry  transmitting,  receiving,  and  signal  processing 
equipment  at  the  member  ranges  under  the  cognizance  of  the  RCC.  The  Range  Commanders 
highly  recommend  that  telemetry  equipment  operated  by  the  ranges  and  telemetry  equipment 
used  in  programs  that  require  range  support  conform  to  these  standards. 

These  standards  do  not  necessarily  define  the  existing  capability  of  any  test  range,  but  constitute 
a  guide  for  the  orderly  implementation  of  telemetry  systems  for  both  ranges  and  range  users. 

The  scope  of  capabilities  attainable  with  the  utilization  of  these  standards  requires  the  careful 
consideration  of  tradeoffs.  Guidance  concerning  these  tradeoffs  is  provided  in  the  text.  The 
standards  provide  the  necessary  criteria  on  which  to  base  equipment  design  and  modification. 
The  ultimate  purpose  is  to  ensure  efficient  spectrum  utilization,  interference-free  operation, 
interoperability  between  ranges,  and  compatibility  of  range  user  equipment  with  the  ranges. 

This  standard,  published  in  two  parts,  is  complemented  by  a  companion  series,  RCC  document 
118,  Test  Methods  for  Telemetry  Systems  and  Subsystems,  and  RCC  document  119,  Telemetry 
Applications  Handbook. 

The  policy  of  the  Telemetry  Group  is  to  update  the  telemetry  standards  and  test  methods 
documents  as  required  to  be  consistent  with  advances  in  the  state  of  the  art.  To  determine  the 
current  revision  status,  contact  the  RCC  Secretariat  at  White  Sands  Missile  Range,  New  Mexico 
at  (505)  678-1107  or  DSN  258-1107  (rcc@wsmr.army.mil). 
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CHAPTER  1 


INTRODUCTION 


1.1  General 


Part  II  of  the  IRIG  106  Telemetry  Standards  addresses  the  standards  specifically  devoted 
to  the  area  of  Telemetry  Networks.  This  part  does  not  stand-alone  and  must  be  used  in 
conjunction  with  Part  I  of  the  106  Telemetry  Standards  to  define  and  implement  a  telemetry 
system. 
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The  concept  of  Telemetry  (TM)  Networks  is  currently  evolutionary.  Initial  releases  of 
this  part  of  the  standard,  while  incomplete,  reflect  those  areas  of  the  technology  mature  enough 
to  define  methods,  techniques,  and/or  specifications  needed  to  ensure  interoperability  among  and 
across  the  ranges.  The  Range  Commanders  Council  (RCC)  Telemetry  Group  (TG)  plan  is  to 
systematically  expand  the  standards  and  information  in  this  part  to  the  point  users  are  able  to 
totally  implement  a  telemetry  network  from  the  acquisition  of  data  through  the  transmission 
and/or  recording  process. 

Rapidly  changing  technology  and  acquisition  reform  have  led  the  Department  of  Defense 
to  rely  more  heavily  on  commercial-off-the-shelf  (COTS)  hardware  and  software.  Consequently, 
existing  and  near  horizon  commercial  communications  standards  are  implemented  or  tailored  to 
the  maximum  extent  possible.  In  general,  the  body  of  any  adopted  or  adapted  standard  is  not 
repeated  in  this  document,  but  is  cited  in  the  list  of  reference  documentation  associated  with  each 
chapter.  The  source  to  obtain  such  documentation  is  cited  in  those  cases  where  the  publications 
are  not  universally  available. 


The  TM  Networks  standards  addressed  here  will  describe  systems  that  use  packetized 
data,  protocols,  and  architectures  similar  to  traditional  computer  networks. 
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CHAPTER  2 


MESSAGE  STRUCTURES 


This  page  intentionally  left  blank. 
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CHAPTER  3 


INTERVEHICULAR  TRANSPORT  PROFILE 


3.1 

Introduction 

3.1.1 

Background. 

Traditional  instrumentation  systems  consist  of  a  PCM  switch  with  many  transducer 
interfaces.  These  systems  were  very  centralized  with  wire  bundles  running  from  the  switch 
throughout  the  test  article.  Trouble-shooting  and  replacing  such  a  system  was  time  consuming 
yet  straightforward.  Distributed  data  systems  split  the  centralized  functions  into  multiple  units 
around  the  test  article.  The  data  acquisition  units  (DAUs)  communicated  via  a  unique  and  often 
proprietary  data  link.  This  factor  increased  the  complexity  of  the  data  system,  but  decreased  the 
effort  to  install  and  modify  the  system.  The  transducer  wiring  was  routed  only  to  the  nearest 
DAU  -  not  all  the  way  back  to  a  central  location. 

As  distributed  systems  became  more  prevalent,  there  was  a  desire  to  mix  and  match 
capabilities  found  in  various  systems.  The  non-standard  data  link  used  between  units  precluded 
such  activity.  The  T&E  community  has  standardized  on  a  common  interconnect  bus.  This  bus 
makes  interchanging  units  between  systems  possible.  To  gain  even  greater  benefit,  this  profile 
targets  a  widespread  commercial  standard  that  can  be  applied  to  test  vehicle  instrumentation. 

3.1.2  Purpose. 

This  Intravehicular  Transport  Profile  is  intended  to  provide  a  starting  point  for 
interoperability  of  Fibber  Channel  end-items  in  a  test- vehicle  instrumentation  environment.  It  is 
envisioned  this  profile  will  be  one  of  a  family  of  interoperability  chapters  in  IRIG  106.  When 
taken  as  a  whole,  interoperability  between  compliant  nodes  will  be  assured.  Since  this  document 
is  focused  at  the  system  level,  the  target  audience  is  both  the  end-item  designers  concerned  about 
interoperability  and  the  instrumentation  engineer  concerned  with  understanding  the  capabilities 
and  tradeoffs  of  such  a  system. 

3.1.3  Scope. 

Some  profiles  provide  a  boundary  limit  to  contain  the  capabilities  of  the  compliant 
devices.  This  profile,  which  takes  a  slightly  different  approach,  specifies  a  minimum  set 
required  to  achieve  interoperability  between  multiple- vendor  end-items  on  a  Fibre  Channel 
instrumentation  bus.  Therefore,  this  profile  is  not  intended  to  limit  the  capabilities  of  a  unit  or 
system.  It  does  require  whatever  capability  the  unit  has  and  it  shall  include  the  capabilities  in 
this  profile  as  a  minimum.  This  document  only  addresses  the  ability  to  move  the  data.  The 
format  of  the  data  is  beyond  the  scope  of  this  document. 
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3.1.4  Precedence. 


The  order  of  precedence  for  instrumentation  interoperability  shall  be  this  document,  the 
FC-AE  profile,  and  the  Fibre  Channel  suite  of  standards. 

3.1.5  Responsibility. 

This  chapter  is  a  result  of  a  joint  effort  between  the  Office  of  the  Secretary  of  Defense 
(OSD)  Central  Test  &  Evaluation  Program  (CTEIP)  Office  and  the  Range  Commanders  Council 
Telemetry  Group.  The  authority  of  this  chapter  remains  with  the  RCC  Telemetry  Group.  The 
Fibre  Channel  documents  referenced  throughout  this  chapter  are  the  responsibility  of  the  Til 
Technical  Committee  (TC)  under  Accredited  Standards  Committee  (ASC)  National  Committee 
for  Information  Technology  Standardization  (NCITS).  In  turn,  NCITS  operates  under  the 
procedures  of  the  American  National  Standards  Institute  (ANSI). 


3.1.6  References. 

ANSI  X3.230-1994 

Information  Technology 

-  Fibre  Channel  Physical  and  Signaling 
Interface  (FC-PH),  1994 

ANSI  X3.297-1997 

Information  Technology 

-  Fibre  Channel  Physical  and  Signaling 
Interface  -  2  (FC-PH-2),  1997 

ANSI  X3.303-1998 

Information  Technology 

-  Fibre  Channel  Physical  and  Signaling 
Interface  -  3  (FC-PH-3),  1998 

ANSI  X3.272-1996 

Information  Technology 

-  Fibre  Channel  Arbitrated  Loop  (FC-AL), 
1996 

ANSI  X3.nnn-200x 

Information  Technology 

-  Fibre  Channel  Arbitrated  Loop  (FC-AL- 
2),  200x 

ANSI  X3.nnn-200x 

Information  Technology 

Fibre  Channel  Avionics  Environment 
Technical  Report 

ANSI  X3.nnn-200x 

Information  Technology 

-  Fibre  Channel  -  Physical  Interfaces  (FC- 
PI) 

-  Fibre  Channel  -  Framing  and  Signaling 

ANSI  X3.nnn-200x 

Information  Technology 

(FC-FS) 

3.2  Fibre  Channel  Deviations  and  Clarifications 


The  following  section  identifies  the  mandatory  changes  to  the  indicated  standards  or 
reports.  The  majority  of  the  changes  are  concerned  with  making  optional  capabilities  mandatory 
or  prohibited  in  order  to  increase  the  likelihood  of  interoperability.  Table  3-1,  which  appears 
later  in  this  chapter,  is  not  meant  to  restrict  the  ability  of  the  end  item.  Rather,  it  is  intended  to 
define  a  minimum  operating  set.  Once  the  requirements  are  met,  additional  features  may  be 
included  provided  they  do  not  interfere  with  interoperable  operation  (for  example,  supporting 
speeds  in  addition  to  1063  Mbaud). 
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3.2.1  Physical. 


3.2. 1.1  Signaling  Rate. 

All  compliant  systems  shall  be  capable  of  operating  at  a  signaling  rate  of  1,062.5  Mb/s. 
Additional  signaling  rates  are  allowed. 

3.2.2  Transmission  Protocol. 


No  further  clarifications  of  the  Fibre  Channel  standard  have  been  defined. 

3.2.3  Signaling  Protocol. 

3.2.3. 1  Port  Type. 

To  preclude  the  requirement  of  any  particular  topology,  NL_PORTs  will  be  required. 
This  will  allow  any  unit  to  be  connected  in  a  point-to-point,  loop,  or  switched  fabric  topology. 

3. 2. 3. 2  Login. 


Fibre  Channel  calls  out  two  methods  to  log  in  to  the  network:  explicit  and  implicit. 
Explicit  logins  require  an  exchange  of  parameters  between  two  units,  or  the  unit  and  the  network, 
to  arrive  at  a  set  of  parameters  acceptable  to  both.  While  this  exchange  may  be  desirable  and 
should  not  be  discouraged,  a  more  practical  approach  is  the  implicit  login.  Implicit  logins  allow 
the  user  to  load  the  unit  with  the  proper  commands,  protocols,  etc.  that  the  network  is  using. 
Implicit  logins  shall  be  supported  for  compliant  systems. 

3. 2. 3. 3  Class  of  Service. 


Each  unit  shall  be  capable  of  operating  with  class  3  service.  Other  classes  of  services 
may  be  utilized  as  required. 

3. 2. 3.4  Clock  Synchronization. 

A  clock  synchronization  service  is  described  in  clause  32  of  EC-ES.  Its  use  requires 
Fabric  Clock  Synchronization  (FCS)  ports  to  minimize  delays  through  a  Fabric.  This  method 
also  requires  that  all  NL_Ports  on  a  loop  be  FCS  capable  ports.  An  FCS  port  is  a  new  concept 
and  may  not  be  readily  available  in  the  field  in  the  near  future.  As  a  result,  neither  the  Fabric  nor 
client  n-bit  counters  are  required.  Since  time  synchronization  within  an  instrumentation  network 
is  crucial,  an  alternate  method  will  be  required. 

Each  node  or  client  of  the  clock  synchronization  server  shall  be  capable  of  storing  a  time 
propagation  delay  value.  If  enabled,  the  delay  value  will  be  added  to  the  time  value  received 
prior  to  synchronizing  the  node’s  internal  clock.  In  order  to  accommodate  the  maximum  delay 
from  a  timeserver  on  a  loop,  a  data  field  able  to  count  to  48,900  ns  is  suggested.  The  method  of 
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formatting  and  sending  the  clock  synchronization  words  is  defined  in  clause  32  of  FC-FS  for 
extended  link  services  (ELS). 


NOTE  / 

L.--,.  / 


1.  When  calculating  the  delay  value,  the  congestion  of  the  network  should  be  taken  into  account. 

2.  A  minor  drawback  of  this  approach  requires  a  prior  knowledge  of  the  network  (e.g., 
individual  node  and  propagation  delays).  With  the  static  nature  of  a  test  instrumentation 
network,  this  factor  should  not  pose  a  problem.  In  the  even  that  FCS  ports  do  gain  wide 
availability,  the  delay  register  can  still  be  used  to  compensate  for  cable  propagation  delays  for 
greater  accuracy. 


3.2.4  Common  Services. 

No  further  definitions  of  the  Fibre  Channel  standard  have  been  developed. 

3.2.5  Upper  Layer  Protocol  Mapping. 

Each  unit  shall  be  capable  of  utilizing  the  Internet  Protocol  (IP).  Additional  protocols 
may  be  used  as  the  situation  warrants. 

3.3  Summary 

Table  3-1,  which  follows,  summarizes  the  requirements  in  section  3.2.  In  the  case  of 
conflict,  section  3.2  shall  take  precedence. 


3-4 


TABLE  3-1.  SUMMARY  OF  INTRA VEHICULAR  TRANSPORT  REQUIREMENTS 

Feature  Status  Change  EC  Std  106 

R  -  Required  I  -  Invocable  A  -  Allowed  P  -  Prohibited  (see  below  for  explanation) 

PH:  FC-PH,  FC-PH-2,  FC-PH-3  AL:  FC-AL  FS:  FC-FS  PI:  FC-PI 

FC-0  Physical 

Data  rate 

3.2.1. 1 

1063  Mbaud 

I 

PH-5.1 

Data  rate  of  133,  266,  531,  2125,  4250 

Mbaud 

A 

PH-5.1 

FC-1  Transmission  Protocol 

3.2.2 

FC-2  Signaling  Protocol 

3.2.3 

NL Port 

R 

3.2.3. 1 

Login 

PH-23 

3.2.3.2 

Implicit  N Port  login 

I 

PH-23,23.4 

Explicit  N Port  login 

A 

PH-23.4.2 

Class  of  Service 

0 

Class  1 

A 

PH-22.1 

Class  2 

A 

PH-22.2 

Class  3 

I 

PH-22.3 

Class  3  multicast 

A 

PH-31 

Class  4 

A 

PH-22.5,  34 

Class  6 

A 

PH-22.6 

Clock  Synchronization 

0 

ELS  method 

I 

FS-32,2 

Primitive  method 

A 

FS-32,3 

Client  delay  value 

I 

New 

Eabric  n-bit  counter 

A 

FS-32.2.2.3 

Client  n-bit  counter 

A 

FS-32.2.2,4 

FS-32.2.3,3 

FC-3  Common  Services 

0 

FC-4  Upper  Layer  Protocol  Mapping 

3.2.5 

Protocols 

IP 

I 

SCSI 

A 

SCPS-NP 

A 

Others 

A 

NOTES  ON  THE  TABLE 

Implementation 

Application 

Required:  That  feature  shall  be  used  between  compliant  units.  The 
hardware  is  required  to  implement  the  feature.  The  application  is  required  to 
use  the  feature. 

Invocable :  The  hardware  is  reauired  to  imolement  the  feature.  However  the 
user  may  choose  whether  to  use  the  feature.  This  provides  a  common  set 
of  requirements  that  are  implemented  in  the  unit  and  available  to  the  user  for 
interoperability  issues. 

Allowed:  That  feature  mav  be  used  between  comoliant  units.  The  hardware 
is  not  required  to  implement  the  feature.  The  application  may  use  the 
feature  if  it  is  available. 

Prohibited!  The  feature  shall  not  be  used  between  comoliant  imolemen- 
tations.  An  implementation  may  use  the  feature  to  communicate  with  non- 
comoliant  imolementations.  This  document  does  not  orohibit  the 
implementation  of  features,  po!y  their  use  between  compliant 
implementations.  However,  interoperability  is  not  guaranteed  if  Prohibited 
features  are  used. 

Required 

Shall 

Shall 

Invocable 

Shall 

May 

Allowed 

May 

May 

Prohibited 

May 

Shall  Not 

The  Fibre  Channel  Standard  Column  (FC  Std) 
indicates  where  the  indicated  item  can  be  found. 
Currently  the  Fibre  Channel  Standard  Physical  and 
Signaling  Interface  set  (FC-PH,  FC-PH-2,  and  FC- 
PH-3)  is  being  rewritten,  combined,  and  then  split 
into  two  volumes:  Fibre  Channel  Physical  Interface 
(FC-PI)  and  Fibre  Channel  Framing  and  Signaling 
(FC-FS).  Once  these  new  documents  are 
published,  this  section  will  be  updated  to  reflect  the 
reference  changes.  It  is  not  expected  to  change  the 
table  any  further  except  where  noted 
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CHAPTER  4 


EXTRAVEHICULAR  TRANSPORT  (WIRELESS) 

4.1  Introduction 

4.1.1  Background. 

This  Range  Commanders  Council  standard  defines  the  recommended  methodology  for 
packet  telemetry  (wireless)  radio  frequeney  transmissions  using  the  Consultative  Committee  for 
Space  Data  Systems  (CCSDS)  data  multiplex  format.  “The  CCSDS  is  an  international 
organization  of  space  agencies  interested  in  mutually  developing  standard  data  handling 
techniques  to  support  spaee  researeh  condueted  exelusively  for  peaceful  purposes.”  (Quoted 
from  their  web  site:  http://www.cesds.org)  To  this  end,  CCSDS  has  developed  an  extensive  list 
of  documents,  including  “Recommendations”  (or  standards),  that  have  potential  applicability  to 
the  RCC  ranges.  A  related  standard,  IRIG  107,  Digital  Data  Acquisition  and  Onboard 
Recording  Standard,  defines  the  format  for  on-board  data  recording.  IRIG  Standard  107  makes 
extensive  use  of  the  CCSDS  packet  telemetry  standard  (see  Chapter  5  of  106  Part  II,  Recording). 

The  eoncept  of  packetized  digital  eommunieations  is  not  new  and  has  been  in  use  for  a 
number  of  years.  The  protocols  used  in  computer  networks,  such  as  TCP/IP,  are  packet  systems. 
Its  utilization  in  the  RF  arena  for  aircraft  and  missile  telemetry  and  for  satellite  communications 
and  telemetry  purposes  is  a  more  reeent  applieation  of  the  eoncept. 

4.1.2  Purpose. 

This  standard  for  RCC  recommended  packet  telemetry  references  the  CCSDS 
Recommendation  and  places  the  “tailored”  requirements  which  are  unique  to  the  RCC  telemetry 
applications  within  the  body  of  IRIG  Standard  106.  The  advantage  of  this  approach  is  two  fold. 
First,  it  eliminates  the  need  to  revise  the  106  doeument  every  time  the  CCSDS  Reeommendation 
changes,  thereby  reducing  the  chances  of  errors  and  additional  paper  work.  Second,  the  CCSDS 
Recommendation  has  a  number  of  parameters  that  can  vary  with  the  application.  In  the  interest 
of  range  interoperability,  those  parameters  will  be  defined  in  the  106  document.  In  this  manner, 
eonstrained  flexibility  ean  be  achieved. 

4.1.3  Scope. 

This  standard  provides  the  tester  with  a  high  degree  of  flexibility  in  the  data  transmitted 
to  the  ground,  including  in-flight  changes  to  the  telemetry  formatting.  Packet  telemetry  has  the 
benefits  of  enabling  the  applieation  of  modem  network  techniques  and  facilitating  multi-source 
additions  and/or  deletions  to  the  test  environments.  This  standard  can  also  employ  techniques 
for  error  detection  and  correction,  as  per  the  CCSDS  recommended  techniques. 
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4. 1 .4  Precedence. 


The  CCSDS  recommendation  for  packetized  telemetry  began  in  the  mid-1980’s  as  a 
baseline  concept  for  spacecraft-to-ground  data  communication,  and  for  missions  that  were  cross- 
supported  between  space  agencies  of  the  CCSDS.  This  packet  telemetry  recommendation 
established  a  common  framework  and  provided  a  common  basis  for  the  data  structures  of 
spacecraft  telemetry  streams.  It  has  allowed  each  agency  to  proceed  coherently  with  the 
development  of  compatible  derived  standards  for  the  flight  and  ground  systems  that  are  within 
their  cognizance  (i.e.,  allowed  the  tailoring  of  the  Recommendation  into  a  local  standard).  A 
derived  (or  tailored)  standard  can  utilize  a  subset  of  the  optional  features  allowed  by  the 
Recommendation  and  may  incorporate  features  not  addressed  by  the  Recommendation. 

4.1.5  Responsibility. 

It  is  the  responsibility  of  the  user  of  this  standard  to  notify  the  support  command  or  range 
in  sufficient  time  to  ensure  compliance  with  this  standard.  This  standard  will  be  treated  in  the 
same  manner  as  a  Class  II  PCM  and,  therefore,  it  will  not  be  automatic  that  each 
command/agency/range  have  the  capability  of  processing  this  format.  Providing  the  supporting 
range  sufficient  time  to  establish  the  ground  processing  part  of  this  format  will  be  in  the  best 
interests  of  participating  organizations.  Compliance  with  this  RCC  standard  for  packet  telemetry 
should  provide  the  customer  another  opportunity  for  cost  savings. 

4.1.6  References. 

4. 1.6.1  Referenced  Standards. 


1)  CCSDS  102.0-B-4  Packet  Telemetry,  Blue  Book,  November  1995. 

2)  CCSDS  713.0-B-l  Space  Communications  Protocol  Specification  (SCPS)  - 

Network  Protocol  (SCPS-NP),  Blue  Book,  May  1999 

4. 1.6.2  Additional  Information. 


3)  CCSDS  lOl.O-B-3 

4)  CCSDS  100.0-G-l 

5)  CCSDS  103.0-B-l 

6)  CCSDS  120.0-G-l 

7)  CCSDS  121.0-B-l 

8)  CCSDS  301.0-B-2 

9)  CCSDS  320.0-B-l 

10)  CCSDS  320.0-B-l 

11)  CCSDS  401. 0-B 


Telemetry  Channel  Coding,  Blue  Book,  May  1992. 
Telemetry  Summary  of  Concept  and  Rationale,  Green  Book, 
December  1987 

Packet  Telemetry  Services,  Blue  Book,  May  1996. 

Lossless  Data  Compression:  Summary  of  Concept  and 
Rationale,  Green  Book,  May  1997. 

Lossless  Data  Compression,  Blue  Book,  May  1997. 

Time  Code  Formats,  Blue  Book,  April  1990. 

CCSDS  Global  Spacecraft  Identification  Field  Code 
Assignment  Control  Procedures,  Blue  Book,  October  1993. 
Cor.  1  Technical  Corrigendum  1  to  CCSDS  320.0-B-l, 
November  1996. 

Radio  Frequency  and  Modulation  Systems — Part  1 :  Earth 
Stations  and  Spacecraft,  Blue  Book,  November  1994. 
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12)  CCSDS411.0-G-3 

13)  CCSDS  412.0-G-l 

14)  CCSDS  501.0-B-l 

15)  CCSDS  A12.0-G-1 

16)  CCSDS  A30.0-G-3 


Radio  Frequency  and  Modulation — Part  1:  Earth  Stations, 
Green  Book,  May  1997. 

Radio  Frequency  and  Modulation  Systems — Spacecraft-Earth 
Station  Compatibility  Test  Procedures,  Green  Book,  May  1992. 
Radio  Metric  and  Orbit  Data,  Blue  Book,  January  1987. 
CCSDS-Related  Implementations,  Green  Book,  November 
1996. 

CCSDS  Glossary,  Green  Book,  July  1997. 


CCSDS  Color  Code 

Document  Type 

RCC  Equivalent 

Blue  Book 
Recommendation 
RCC  Standard 

Red  Book/Pink  Sheets 
Draft  Recommendation 
Draft  Standard  or  “Pink  Sheets” 

Green  Book 
Report 


4.2  Packet  Telemetry 

4.2.1  General. 


Packet  telemetry  provides  an  alternative  to  traditional  time-division-multiplexing  “PCM” 
methods  which  are  predominantly  based  on  repeated  sampling.  Packet  telemetry  methods 
provide  a  means  for  many  sources  to  transmit  data  to  many  destinations  via  a  single  link  in  a 
packet  switching  environment.  This  is  often  done  as  a  “common  carrier”  service  without 
knowledge  of  the  contents. 
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NOTE  / 

L-. ,  / 


This  section  does  not  define  word  boundaries  or  means  to  decode  data  down  to  the  measurement, 
sample,  or  word  level  comparable  to  the  preceding  sections  ofIRIG  Standard  106-01,  Part  I, 
Chapter  4.  Future,  more  detailed,  standardization  may  be  required  for  specific  application 
areas. 


4.2.2  Scope  of  Application. 

The  most  widely  used  international  approaeh  to  paeket  telemetry  was  developed  by  the 
CCSDS  through  “Packet  Telemetry,”  Recommendation  CCSDS  102.0-B-4,  November  1995 
(Ref.  #1).  Packet  telemetry  described  herein  is  an  application  of  that  Recommendation.  Only 
limited  portions  of  that  document  are  shown  in  this  section;  however,  the  full  Recommendation 
is  included  by  reference.  Also  included  by  reference  is  the  SCPS-NP  packet  definition  in 
CCSDS  713.0-B-l,  May  1999  (Ref.#2). 
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4.2.3  Benefits. 


Packet  telemetry  provides  the  benefits  of  enabling  the  application  of  modern  network 
techniques  and  facilitating  multi-source  to  multi-user  test  environments  but  incurs  an  inherent 
added  latency  and  overhead  which  may  or  may  not  be  suitable  for  some  Range  users. 

4.2.4  Concept. 

The  CCSDS  Packet  Telemetry  Recommendation  (Ref  #1)  contains  the  essence  of  the 
packet  telemetry  concept,  which  permits  multiple  application  processes  onboard  a  test  article  to 
create  data  that  is  best  suited  to  the  data  source  (whether  an  instrument  or  a  sub-system)  and  to 
format  the  information  for  transmission  to  the  ground  system  for  recovery  and  dissemination  to 
multiple  users.  Citing  from  Ref.  #1:  “To  accomplish  these  functions,  the  Recommendation 
defines  two  data  structures  -  SOURCE  PACKETS  and  TRANSFER  FRAMEs  -  and  a 
multiplexing  process  to  interleave  SOURCE  PACKETS  from  various  APPLICATION 
PROCESSES  into  TRANSFER  FRAMES.” 

4.2.5  Summary. 

Packet  TM  using  CCSDS  Recommendations  consists  of  source  packets  multiplexed  into 
transfer  frames  of  virtual  channels  that  are  then  multiplexed  into  a  Master  Channel.  If  a  user 
does  not  invoke  “Virtual  Channel”  concepts  for  serving  many  user  groupings,  the  transfer  frames 
are  simply  multiplexed  into  a  Master  Channel.  See  Fig.  4-1  for  clarification  of  these  terms.  For 
a  complete  definition  of  this  process  consult  Ref.  #1. 
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Figure  4-1.  Packet  Telemetry  Data  Flow 
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4.3 


Source  Packet 


4.3.1  Structure  and  Content. 

The  source  packet  is  the  fundamental  data  structure  generated  by  an  on-board  application 
process.  It  contains  a  packet  header  and  the  data  that  is  under  control  of  the  application  process. 
The  normal  CCSDS  packet  structure  is  replicated  in  Fig.  4-2  as  an  example.  Another  example  is 
the  SCPS-NP  packet  defined  in  Ref.  #2.  Souree  information  content  is  optional  and  depends  on 
user  implementation.  Any  type  of  packet  used  shall  contain  Packet  Length  and  Version  Number 
in  aeeordanee  with  the  protoeol  in  use.  Coneurrenee  from  the  range  involved  should  be  acquired 
to  ensure  compatibility. 

y  NOTE 

For  noisy  channels  where  bit  errors  and  bit  slips  are  likely,  it  is  recommended  that  the 

PACKET  SIZES  BE  RESTRICTED  TO  CLASS  I  OR  CLASS  II SUBERAME  MAXIMUM  LENGTHS  (SEE  CH.4, 

IRIG 106,  Part  I,  Fig.  4-2)  to  minimize  the  loss  oe  data.  See  additional  recommendations 

IN  Ref.  #I. 


4.3.2  Format. 
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Set  to  “11”  -  no  grouping 

Type  Indicator 

Set  to  “0”  for  telemetry 


Packet  Sec  Hdr  Flag 

“0”  if  Sec.  Hdr.  is  not  present 

“1”  if  Sec.  Hdr.  Is  present 

Source  Seq  Count 

Sequential  binary  count  of  each  packet  with  the  same  Application  Process  ID 
Application  Process  ID 

Different  for  each  Process  on  Same  Master  Channel 
All  I’s  for  Idle  packet,  “11111111111” 

Packet  Data  Length 

Binary  number  of  the  number  octets  minus  one  in  the  data  field 


Figure  4-2.  Source  Packet  Format  (Ref.  #1) 

4.4  Transfer  Frame 

The  transfer  frame  provides  the  structure  for  transmission  over  a  noisy  RF  channel  from 
the  test  article  to  the  receiver.  It  shall  be  of  constant  length  during  the  mission  and  is  limited  to 
8920  bits,  not  including  the  Attached  Synchronization  Marker  (ASM)  that  precedes  the  transfer 
frame.  The  ASM  is  analogous  to  the  minor  frame  synchronization  word  of  the  PCM  (see 
paragraph  4.3. 2. 1.3  of  IRIG  106  Part  I),  but  is  fixed  in  length  at  32  bits.  The  recommended 
synchronization  pattern  of  32  bits  is  given  in  table  C-1,  appendix  C  (IRIG  106  Part  I).  The 
transfer  frame  structure  is  shown  in  figure  4-3.  The  fields  within  the  transfer  frame  are  defined 
as  follows  (for  additional  details  see  Ref.  #1): 


Header  Descriptor 


Bits 


Transfer  Frame  Version  Number  Set  to  “00” 


Test  Article  (Spacecraft  ID) 


Virtual  Channel  Identifier 


The  test  article  identifier  shall  be  negotiated  with  the 
Test  Range.  For  spacecraft  operating  under  the 
CCSDS  see  Ref.  #1  par.  5.1.2.1c 

Identifies  the  virtual  channel  being  transmitted  (1  of  8) 


Operational  Control  Field  Flag 


“1”  if  operational  control  field  is  present,  “0”  if 
operational  control  field  is  not  present 


Master  Channel  Frame  Count  Field  A  running  count  or  sequence  identifier  of  each  transfer 
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frame  transmitted  within  the  Master  Channel 


Virtual  Channel  Frame  Counter  Field 

A  running  count  or  sequence  identifier  for  each 
transfer  frame  transmitted  through  a  specific  virtual 
channel  of  a  master  channel 

Transfer  Frame  Secondary  Header  Flag 

“1”  if  the  transfer  frame  secondary  header  is 
present,  “0”  if  the  secondary  header  is  not  present 

Synchronization  Flag 

“0”  if  octet-synchronized  and  forward-ordered  source 
packets  or  idle  data  are  inserted,  “1”  if  privately 
defined  data  are  inserted 

Packet  Order  Flag 

Not  used/undefined.  Set  to  “0” 

Segment  Length  Identifier 

Not  used/undefined.  Set  to  “0” 

First  Header  Pointer 

If  the  Sync  Flag  is  “0”,  the  first  header  pointer 
identifies  the  position  of  the  first  source  packet  within 
the  transfer  frame  data  field.  The  pointer  contains  a 
binary  representation  of  the  location  of  the  first  octet 
of  the  first  packet  primary  header.  Numbering  with 
the  first  octet  being  “0”. 

If  no  packet  primary  header  starts  in  the 

TRANSFER  FRAME,  THE  FIRST  HEADER  POINTER  IS  SET 

TO“UlllllIII  I”.  If  idle  data  is  contained  in 

THE  TRANSFER  FRAME  DATA  FIELD,  THE  POINTER  IS 

SETTO“HIIIIIIII0”. 

If  sync  flag  is  “1”,  the  header  is  undefined. 

Transfer  Frame  Sec  Hdr  Ver  No. 

Set  to  “00” 

Transfer  Frame  Secondary  Header 
Length 

Length  of  the  secondary  header  in  octets  minus  one, 
represented  as  a  binary  number. 

Transfer  Frame  Secondary 

Contains  the  secondary  header  data,  up  to  63  Octets. 

Transfer  Frame  Data  Field 

Contains  the  data  to  be  transmitted  to  the  receiving 
site  and  shall  consist  of  an  integral  number  of  octets. 
The  data  may  consist  of  source  packets,  idle  data,  and 
privately  defined  data.  To  maintain  synchronization 
with  the  receiving  station,  idle  data  is  transmitted 
whenever  insufficient  data  from  other  sources  is  not 
available 

Operational  Control  Field 

This  field  is  set  to  0  (used  only  for  telecommand).  See 
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Ref.  #  1  for  definition  and  applications. 


Frame  Error  Control  Field  This  (*)  field  is  optional  only  if  the  transfer  frame  is 

contained  within  the  data  space  of  a  Reed-Solomon 
Code  Block.  It  is  mandatory  if  Reed-Solomon  is  not 
used.  See  Ref.  #1  for  more  descriptive  information. 


NOTE  / 

L. . ,  / 

The  Operational  Control  Field  (used  for  Telecommand)  is  not  present  in  IRIG  106  and  the 
corresponding  Operational  Control  Field  Flag  is  set  to  zero.  They  are  shown  here  in  the 
Transfer  Frame  Format  only  for  clarity  and  consistency  with  CCSDS  standards. _ 


4.4.1  Master  Channel. 


In  most  instances  the  Master  Channel  is  identical  to  the  data  organization  in  the  physical 
channel  used  for  transmission.  In  Ref.  #1,  however,  the  Master  Channel  is  defined  as:  “All 
transfer  frames  with  the  same  transfer  frame  version  number  and  the  same  spacecraft  identifier 
(read  test  article)  on  the  same  physical  channel.”  In  this  standard,  the  physical  channel  is  taken 
to  be  a  transmitter-receiver  radio  link. 

4.4.2  Virtual  Channelization. 


Virtual  Channel  utilization  enables  independent  users  of  the  common  RF  link  to  view 
their  data  (and  entire  “formats”  in  traditional  terms)  as  exclusive  and  separate.  Virtual 
Channelization  is  also  a  mechanism  for  multiplexing  data  from  a  number  of  different  sources  so 
channel  capacity  and  access  can  be  assigned  and  allocated  on  a  priority  basis.  In  addition  it 
provides  for  accumulating  data  by  grouping,  which  can  expedite  the  transfer  of  received  data  to 
the  user.  For  additional  information  on  virtual  channels  see  “Telemetry  Summary  of  Concept 
and  Rationale,”  Report  Concerning  Space  Data  Systems  Standards,  CCSDS  100.0-G-l.  Green 
Book.  Issue  1.  Washington,  DC:  CCSDS,  December  1987. 
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APPENDIX  A 

COMMON  ABBREVIATIONS  &  DEFINITIONS 


A-l 


Arbitrated  Loop  -  A  Fibre  Channel  topology  where  nodes  are  linked  together  in  a  closed  loop. 
Traffic  is  managed  with  a  token-acquisition  protocol,  and  only  one  connection  can  be  maintained 
in  the  loop  at  a  time. 

Class  1  -  Dedicated  connection  allocating  full  bandwidth  between  a  pair  of  ports.  Class  1 
provides  confirmation  of  delivery  or  notification  of  non-delivery  between  the  source  and 
destination  ports. 

Class  2  -  Connectionless  class  of  service  with  confirmation  of  delivery  or  notification  of  non- 
deliverability  of  frames.  No  bandwidth  is  allocated  or  guaranteed. 

Class  3  -  Connectionless  class  of  service  providing  a  datagram-like  delivery  service  with  no 
confirmation  of  delivery,  or  notification  of  non-delivery. 

Class  4  -  Connection  oriented  class  of  service  which  provides  a  virtual  circuit  between  a  pair  of 
ports  with  guaranteed  fractional  bandwidth  and  latency  with  confirmation  of  delivery  and 
notification  of  non-delivery. 

Class  6  -  A  derivative  of  class  1  that  provides  a  reliable  one-to-many  multicast  service  with 
confirmation  of  delivery  and  notification  of  non-delivery. 

classes  of  service  -  Different  types  of  services  provided  by  the  Fabric  and  used  by  the 
communicating  N_Ports. 

command-response  architecture  -  A  network  containing  a  device  which  controls  the  access  of 
the  other  nodes  to  the  network. 

counter-rotating  ring  -  An  arrangement  whereby  two  signal  paths,  the  directions  of  which  are 
opposite,  exist  in  a  physical  ring  or  loop  topology. 

r_Port  -  Fabric  Port  -  A  Fibre  Channel  term  referring  to  the  port  residing  on  the  Fabric 
(Switch)  side  of  the  link.  It  attaches  to  a  Node  Port  (N_Port)  at  the  connected  device,  across  a 
link. 

FL_Port  -  An  F_Port  that  contains  Arbitrated  Loop  functions  associated  with  Arbitrated  Loop 
topology. 

fabric  -  denotes  the  interconnect  of  ports  without  regard  to  topology 

Fabric  -  A  transport  medium  that  provides  switched  interconnects  between  ports.  Fabric 
specifies  a  topology  distinct  from  Point-to-Point  and  Arbitrated  Loop. 

Fibre  Channel  -  An  ANSI  communication  standard  that  can  utilize  either  copper  or  fiber  optic 
cable  plants. 

informative  -  Information  provided  for  completeness.  Not  required  for  standard  compliance. 
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interoperability  -  The  capability  to  communicate  or  transfer  data  among  various  functional  units 
in  a  manner  that  requires  the  user  to  have  little  or  no  knowledge  of  the  unique  characteristics  of 
those  units. 

Internet  Protocol  (IP)  -  Part  of  the  TCP/IP  family  of  protocols  describing  software  that  tracks 
the  Internet  address  of  nodes,  routes  outgoing  messages,  and  recognizes  incoming  messages. 

N_Port  -  Node  Port.  A  Fibre  Channel  term,  referring  to  the  link  control  facility  which  connects 
across  a  link  to  the  Fabric  Port  (F_Port)  at  the  Fabric  (switch). 

NL_Port  -  An  N_Port  that  contains  Arbitrated  Loop  functions  associated  with  Arbitrated  Loop 
topologies. 

node  -  A  point  of  connection  into  a  network.  In  Fibre  Channel,  a  collection  of  one  or  more 
N_Ports. 

node  synchronization  -  The  ability  to  time  synchronize  two  or  more  nodes  to  a  common  time 
base. 

OEM  -  Original  Equipment  Manufacturer 

open  systems  -  Everyone  would  comply  with  a  set  of  hardware  and  software  standards. 

peer-to-peer  architecture  -  A  network  that  contains  equivalent  nodes  with  respect  to  their 
capability  of  control  or  operation. 

Point-to-Point  -  Fibre  Channel  topology  in  which  communication  between  two  N_Ports  occurs 
without  the  use  of  Fabric. 

port  -  Network  access  point  for  data  entry  or  exit.  In  Fibre  Channel,  a  generic  reference  to  an 
N_Port  or  F_Port. 

protocol  -  A  procedure  for  adding  order  to  the  exchange  of  data.  A  specific  set  of  rules, 
procedures,  or  conventions  relating  to  format  and  timing  of  data  transmission  between  two 
devices. 

simultaneous  sampling  -  Acquiring  multiple  data  samples  within  a  given  time  period. 

time  correlation  -  The  ability  to  correlate  two  or  more  data  samples  with  respect  to  the  time  they 
were  sampled. 

time  synchronization  -  The  ability  to  synchronize  two  or  more  sources. 
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INSTRUMENTATION  SYSTEM  ISSUES  (INFORMATIVE) 


This  section  provides  insight  to  ideas  that  may  affect  a  Fibre  Channel  instrumentation 
system.  It  is  based  on  the  bus  requirements  identified  early  in  the  NexGenBus  project. 
Requirements  are  not  to  be  construed  from  this  section. 

B.l  Architecture 


Figure  B-1  Controller  Based  Architecture 
B .  1 . 1  Controller  B  ased  Architecture . 


The  Fibre  Channel  by  itself  does  not  imply  the  type  of  architecture  an  instrumentation  system 
must  utilize.  There  are  two  basic  architectures  that  can  be  employed  in  the  design  of  the  system. 

The  nodes  may  or  may  not  support  both  architectures.  In  the  traditional  system,  a  controller  or 
master  is  used  to  command  the  nodes  and  receive  the  responses.  The  controller  is  programmed  with 
the  knowledge  of  the  overall  format  and  directs  each  node  to  acquire  data  and  respond  (reference 
Figure  B-1).  The  controller  typically  becomes  the  aggregator  of  the  data  as  it  formats  the  output(s) 
for  recording,  transmitting,  or  processing.  This  architecture  keeps  the  nodes  simple.  Traffic  on  the 
bus  is  very  orderly  based  on  what  the  controller  requests.  This  is  also  known  as  a  command- 
response  architecture.  Multiple  formats  can  be  stored  in  the  controller  and  changed  via  a  cockpit 
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switch  or  sophisticated  uplink.  Controllers  can  vary  from  small  inexpensive  units  that  are  inflexible 
to  large  expensive  units  that  ean  do  everything. 

B .  1 .2  Peer-to-Peer  Architecture. 


Another  architecture  available  to  the  instrumentation  network  is  the  peer-to-peer 
architecture,  wherein  each  node  is  programmed  with  its  own  schedule.  Individually  the  nodes 
determine  when  to  aequire  the  data,  how  to  packetize  the  data,  whom  to  send  it  to,  and  how  often 
to  send  it  (reference  Figure  B-2).  One  of  the  advantages  of  an  autonomous  system  is  the  ease  at 
which  new  nodes  may  be  added.  Additional  nodes  just  need  to  be  physically  connected  to  the 
bus  and  programmed.  The  other  nodes  are  not  affected  (assuming  there  is  plenty  of  bandwidth 
on  the  bus).  One  node  eould  still  receive  all  the  data  and  format  it  into  the  proper  outputs  for 
recording  and  transmitting  similar  to  the  command  response  architecture. 


Figure  B-2  Peer-to-Peer  Arehiteeture 


B.2  Open  System 

In  an  open  system,  the  specifications  are  generally  in  the  publie  domain.  Of  particular 
importance,  the  specifications  should  be  in  wide  use  as  well.  This  system  allows  ready  access 
not  only  to  the  specifications  but  also  to  the  chipsets,  OEM  boards,  drivers,  and  test  equipment. 

B.3  Topology 

Fibre  Channel  defines  three  major  topologies:  point-to-point,  fabric,  and  arbitrated  loop. 
Another  topology  available  is  hybrid  topology. 
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B.3.1  Point-to  Point  Topology. 


The  point-to-point  topology  is  the  simplest.  It  connects  two  ports  with  a  bi-directional 
link  consisting  of  a  transmit  cable  and  a  receive  cable  (reference  Figure  B-3). 


Figure  B-3  Point-to-Point  Topology 
B.3.2  Fabric  Topology. 

In  the  Fabric  topology,  each  node  is  connected  to  a  switch.  Depending  on  the  capabilities 
of  the  switch,  any  node  may  connect  to  any  other  node  (reference  Figure  B-4).  When  denoting 
Fabric  topologies,  the  Fabric  is  shown  as  a  cloud.  This  represents  the  Fabric  notion  without 
showing  any  physical  connections.  One  of  the  drawbacks  of  Fabric,  is  the  requirement  for  one  or 
more  Fabric  switches  that  physically  take  the  place  of  the  network  cloud.  These  switches  are  not 
necessarily  cheap  -  especially  for  a  test  environment.  Because  of  the  connectivity,  adding 
additional  nodes  increases  the  total  bandwidth  available  to  the  system.  In  reality,  this  is  only  true 
if  there  is  a  broad  distribution  of  network  traffic.  If  all  nodes  are  trying  to  talk  through  one  link 
to  the  recorder,  then  more  nodes  will  only  make  it  worse. 


Figure  B-4  Fabric  Topology 
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B.3.3  Arbitrated  Loop  Topology 


The  arbitrated  loop  topology  is  a  simple  concatenation  from  the  transmitter  of  one  node 
to  the  receiver  of  the  next.  This  progresses  through  all  nodes  until  the  last  transmitter  is 
connected  to  the  first  receiver  to  form  a  loop  (reference  Figure  B-5).  Simplicity  is  one  of  the 
advantages  of  a  loop.  There  is  no  additional  network  hardware  required  for  connectivity.  To  add 
more  nodes,  the  loop  is  broken  with  the  additional  nodes  being  inserted  between  the  break.  One 
of  the  drawbacks  of  a  loop  is  the  constant  bandwidth.  Regardless  of  the  number  of  nodes,  they 
all  share  the  same  bandwidth. 


Figure  B-5  Arbitrated  Loop  Topology 


B.3.4  Hybrid  Topology. 

The  last  type  of  topology  available  is  the  hybrid  topology,  which  simply  replaces  one  of 
the  fabric  nodes  with  a  loop.  Conversely,  it  replaces  a  loop  node  with  a  fabric  (reference  Figure 
B-6).  Figure  B-6  depicts  one  instance  of  a  hybrid  topology;  there  are  many  other  variations. 
Understandably,  the  hybrid  topology  embodies  the  pros  and  cons  of  both  the  fabric  and  loop 
topologies. 


Figure  B-6  Hybrid  Topology 
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B.4  Fault  Tolerance 


In  the  systems  most  instramentation  engineers  are  familiar  with,  a  single  point  failure  has 
rarely  brought  a  system  to  its  knees.  With  traditional  instrumentation  systems,  a  faulty 
connection  on  a  data  acquisition  unit  simply  meant  no  data  would  come  from  that  unit.  The  rest 
of  the  system  would  continue  to  operate  as  is  true  for  MIL-STD-1553  systems.  With  switched 
fabric  systems,  the  switches  become  a  single  point  failure.  One  single-point-failure  mode  does 
not  seem  like  a  big  issue.  Current  systems  have  a  single  point  failure  in  the  system  controller. 
When  we  consider  arbitrated  loop  systems  -  each  node  on  the  loop  is  a  single-point-failure 
source.  There  are  several  ways  to  make  these  systems  more  fault  tolerant  such  as  port  bypass 
circuitry,  hubs,  and  built  in  redundancy. 

B.4.1  Port  Bypass 

One  way  to  add  fault  tolerance  to  a  loop  topology  is  to  add  port  bypass  circuitry  to  each 
node.  If  something  happens  to  the  node  (loss  of  power  or  other  problem)  the  bypass  kicks  in  and 
allows  the  loop  to  continue  to  operate.  The  node  designer  must  add  this  circuitry  to  the  unit  prior 
to  production.  The  port  bypass  circuit  will  not  help  a  faulty  connection  to  the  port  itself. 

B.4.2  Hub 


A  hub  allows  a  logical  loop  topology  to  be  physically  connected  in  a  star  fashion.  The 
hub  acts  as  a  security  guard  monitoring  the  health  of  each  of  the  ports.  When  it  detects  a  failure 
on  one  of  the  ports  or  links,  it  bypasses  the  faulty  link  within  the  hub  (reference  Figure  B-7).  In 
this  way,  a  port  and  its  associated  wiring  can  be  completely  removed  and  not  affect  the  system. 
This  works  well,  however,  many  of  the  drawbacks  of  the  switched  fabric  topology  have  been 
reintroduced  (e.g.,  the  added  expense  (hardware  and  time)  of  routing  the  links  back  to  a  central 
location  as  well  as  the  cost  and  maintenance  of  the  hub). 


Figure  B-7  Arbitrated  Loop  with  Hub 
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B.4.3  Redundancy 


Another  solution,  which  must  be  designed  into  the  port,  is  a  redundant  bus.  For  fabrics,  it 
means  multiple  ports  on  each  node.  Each  port  is  connected  to  the  fabric  and  receives  its  own 
port  address.  The  node  is  responsible  for  merging  data  from  among  its  ports.  To  the  rest  of  the 
fabric,  it  looks  like  there  are  more  ports.  For  the  data  rates  expected  in  initial  instrumentation 
systems,  wholesale  redundant  busses  for  fabrics  do  not  seem  to  gain  much.  However,  the 
concept  of  multiple  ports  for  high  bandwidth  data  sinks  like  recorders  seems  to  have  merit.  For 
loops,  an  additional  connection  between  nodes  in  the  opposite  direction  may  be 
installed.  This  creates  a  counter-rotating  ring.  If  there  is  a  connection  failure,  data  can  still 
traverse  the  ring. 

B.4.4  Avionics  Busses 

Avionics  Busses  used  to  control  the  test  vehicles  have  typically  had  redundancy  built  into 
the  system.  Given  the  criticality  of  a  failure  for  operational  systems,  it  is  essential.  Redundancy 
in  instrumentation  systems  has  been  the  exception  rather  than  the  rule.  A  Fibre  Channel  system 
built  to  the  ANSI  standards  has  a  lower  bit  error  rate  than  anything  used  previously.  The  system 
designer  must  decide  if  redundancy  is  required  for  a  given  implementation.  Possible  choices 
include  counter  rotating  rings  and  dual  ported  nodes. 

B.4.5  Addressing 

When  a  port  logs  into  the  fabric,  or  when  the  loop  is  initialized,  the  port  addresses  are 
assigned.  Fibre  Channel  allows  a  port  to  request  a  previously  assigned  address.  It  allows  the 
ports  to  request  an  address  on  a  cold  start.  The  primary  concern  is  for  systems  where  new  nodes 
may  be  coming  online  at  random  or  under  some  other  control.  Since  the  test  vehicle  is  a  private 
system  where  the  instrumentation  engineer  has  the  knowledge  of  what  nodes  are  in  the  system, 
static  addresses  should  not  be  a  problem.  The  ability  to  preset  an  address  is  an  advantage  for 
many  reasons,  not  the  least  of  which  is  trouble-shooting. 

B.5  Timing 

Timing  is  one  of  the  most  critical  issues  facing  instrumentation  networks.  There  are  three 
major  timing  issues:  time  correlation  of  data,  simultaneous  sampling,  and  the  reconstruction  of 
data  sources.  Synchronizing  the  nodes  to  a  common  time  source,  if  done  accurately  enough, 
could  solve  all  three  issues.  The  question  of  what  accuracy  is  required  is  still  open  to  debate.  It 
may  be  overridden  by  what  is  achievable.  The  issues  surrounding  the  ability  to  synchronize 
differ  with  each  topology  selected. 

B.5.1  Data  Correlation 

Time  correlation  of  data  requires  knowledge  of  when  a  sample  occurred  in  relation  to 
other  samples.  If  both  samples  occur  within  the  same  node,  the  issue  is  trivial.  When  they  occur 
across  different  nodes,  the  time  relationship  between  the  nodes  needs  to  be  known. 
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B.5.2  Simultaneous  Sampling 


In  some  instances,  knowing  when  different  samples  occurred  is  not  good  enough.  The 
samples  need  to  be  acquired  at  the  same  moment  in  time  for  data  processing  issues  to  be  reduced 
to  a  manageable  level. 

B.5.3  Data  Source  Reconstruction 

Data  source  reconstruction  is  similar  to  data  correlation,  but  a  bit  more  specific.  For 
some  data  sources,  like  MIL-STD-1553  data  busses,  the  user  wants  to  recreate  the  bus  exactly 
for  use  with  simulators  or  trouble-shooting  equipment.  In  a  packet-based  environment,  each 
packet  will  be  stamped  with  the  time  of  arrival.  The  fidelity  of  the  time  stamps  will  vary  with 
the  requirement  for  reconstruction. 

B.6  Interoperability 

This  section  will  explain  some  of  the  rationale  by  which  certain  values  are  selected. 

B.6.1  Cables  and  Connectors 

The  Fibre  Channel  standards  were  written  with  benign  environments  in  mind.  Because  of 
space  constraints  within  test  vehicles,  signal  wires  are  sometimes  tied  in  the  same  bundles  as 
power  lines  and  antenna  cabling.  The  proximity  of  radars,  avionics,  and  power  distribution  units 
creates  an  environment  most  cable/connector  sets  cannot  tolerate.  Because  of  this  harsh 
environment,  the  physical  component  was  expected  to  deviate  from  the  standard.  Changing  the 
physical  level  should  not  affect  the  ability  to  leverage  the  commercial  industry. 


B.6.2  Port  Type 

Since  this  is  an  interoperability  document,  it  was  decided  not  to  arbitrarily  choose  a 
topology.  Because  there  are  pros  and  cons  to  both  port  types,  the  system  designer  should  decide 
what  is  best  for  the  application.  The  selection  of  the  NL_Port  allows  any  of  the  topologies  to  be 
used. 

B.6.3  Signaling  Rate 

For  two  nodes  to  communicate,  they  must  operate  at  the  same  signaling  rate.  Full  speed 
is  by  far  the  most  prevalent  rate  and  the  one  most  vendors  will  design  into  their  units.  This 
preference  does  not  preclude  the  use  of  additional  rates  like  quarter  speed  or  double  speed,  but 
will  ensure  that  all  units  have  a  common  rate  with  which  to  communicate. 

B.6.4  Login 

Since  the  instrumentation  network  is  a  private  network,  the  system  designer  knows  what 
nodes  are  going  to  be  put  on  the  network  and  how  they  need  to  operate.  Therefore,  the  login 
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parameters  can  be  preloaded  and  stored  internally.  Explicit  login  appears  more  like  an  “auto- 
negotiate”  routine,  which  adds  a  level  of  complication.  Probably  the  greater  concern  is  to  ensure 
the  variety  of  login  parameters  allows  interoperability.  For  example,  do  we  need  to  define 
default  common  service  parameters  for  FLOGI  and/or  PLOGI? 

B.6.5  Class  of  Service 

Much  the  same  as  signaling  rate.  Fibre  Channel  allows  several  choices.  However,  class 
three  seems  to  be  the  most  prevalent  class  of  service.  Again,  this  does  not  preclude  the  use  of 
other  classes. 

B.6.6  Protocol 

Since  NexGenBus  did  not  study  the  upper  layer  protocols  (ULP),  selecting  the  most 
capable  protocol  is  out  of  the  question.  The  most  prevalent  ULP  seems  to  be  the  only  choice. 

The  ULP  used  frequently  on  Fibre  Channel  is  the  SCSI  protocol.  This  protocol  has  been  used  for 
years  for  read/write  commands  between  a  host  (PC)  and  a  target  (tape  drive).  Because  of  Fibre 
Channel’s  robust  architecture  and  low  latency  to  send  and  receive  SCSI  commands,  the  use  of 
SCSI  in  a  Storage  Area  Network  (SAN)  has  become  almost  universal.  Recently  the  use  of 
TCP/IP  drivers  on  Fibre  Channel  has  become  popular.  The  use  of  TCP  provides  the  ability  to 
interoperate  with  many  different  devices.  The  penalty  is  that  TCP  uses  a  connection  oriented 
protocol  in  which  acknowledgments  are  received  for  each  packet.  This  characteristic  creates 
additional  traffic  on  the  network,  which  in  turn  reduces  throughput  and  increases  latency.  An 
alternative  to  TCP  is  UDP,  which  uses  the  same  size  packet,  etc.,  but  does  not  acknowledge 
packets  received.  This  characteristic  increases  throughput  and  decreases  latency.  Although  not 
strictly  an  upper  layer  protocol,  the  Internet  Protocol  (IP)  is  the  most  pervasive  protocol  in  use 
today.  It  provides  a  connectionless  method  of  connecting,  but  has  a  rich  set  of  tools  developed 
for  the  Internet.  The  IP  Protocol  is  used  with  either  TCP  or  UDP.  Many  vendors  are  providing 
IP  drivers  along  with  their  SCSI  drivers. 
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C.l  Physical  Interface 


The  physical  interface  is  the  first  test  of  interoperability.  If  the  units  cannot  be  physically 
connected  together  via  an  electrical  or  fiber  optic  cable,  interoperability  is  squashed  right  off  the 
bat.  The  cable  and  connector  are  usually  selected  together  since  selecting  one  will  limit  the 
choices  for  the  other.  The  original  Tibre  Channel  Physical  and  Signaling  Interface”  (FC-PH) 
standards  called  out  allowable  cables  and  connectors  in  chapters  7  and  9.  The  new  rewrite  of  the 
FC-PH  three  volume  set  into  one  ‘Fibre  Channel  Physical  Interfaces”  (FC-PI)  standard  is 
currently  in  draft.  The  new  approach  does  not  call  out  cable  specifications  or  lengths.  Instead, 
they  provide  specs  to  which  the  implementer  must  adhere.  A  portion  of  section  10.2  from  the 
FC-PI  draft  standard  states: 


Part  of  FC-PI  draft  v7.3,  section  10.2  Cable  Interoperability 

All  styles  of  balanced  cables  are  interoperable;  i.e.,  electrically  compatible  with  minor  impact  onTxRx 
Connection-length  capability  when  intermixed.  The  unbalanced  (coaxial)  cables  are  also  interoperable. 
Interoperability  implies  that  the  transmitter  and  receiver  level  and  timing  specifications  are  preserved, 
with  the  trade-off  being  distance  capability  in  an  intermixed  system.  Any  electrically  compatible, 
interoperable  unbalanced  or  balanced  cables  may  be  used  to  achieve  goals  of  longer  distance,  higher 
data  rate,  or  lower  cost  as  desired  in  the  system  implementation,  if  they  are  connector,  impedance,  and 
propagation  mode  compatible. 

When  cable  types  are  mixed,  it  is  the  responsibility  or  the  implementer  to  validate  that  the  lengths  of 
cable  used  do  not  distort  the  signal  beyond  the  received  signal  specifications  referenced  in  clause  9.9 
“Receiver  characteristics.” 


C.2  Cable  Connector  Pairs 


Because  of  the  direction  the  Fibre  Channel  standards  group  is  taking  on  identifying 
cables,  this  appendix  will  follow  their  lead.  The  following  sections  identify  a  couple  of 
cable/connector  pairs  that  have  been  tested  using  a  very  small  sample  size.  The  intent  was  to 
show  they  could  be  used  -  not  they  would  work  up  to  n  feet  and  under  x  conditions.  The  unit 
designer  should  use  cables  and  connectors  appropriate  for  the  application.  Consideration  should 
be  given  to  the  user  application  environment.  Industry  common  balanced  and  unbalanced 
connectors  help  the  user  in  minimizing  test  cables  in  labs,  stockpiling  of  connector  types,  and 
using  existing  wiring  in  test  articles.  For  more  information  regarding  the  tests  performed  on 
these  cables,  see  document  number  NGB-OO-DOC-7  (http://nexgenbus.nawcad.navy.mil). 

C.2.1  Balanced 

The  Gore  Quad  Cable  using  MIL-C-38999  style  connectors  with  impedance  matching 
inserts  as  found  to  be  acceptable  for  inter-enclosure  use. 

C.2.2  Unbalanced 

The  RG-302  Cable  (military  grade  of  RG-59)  using  BNC  type  connectors  was  found  to 
be  acceptable  for  intra-enclosure  use. 
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